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ABSTRACT 


The purpose of the thesis is to analyze Marine Corps efforts to comply with the Joint 
Requirements Oversight Council (JROC) directive for a single Joint Blue Force 
Situational Awareness (JBFSA) capability. The shared battlespace is saturated with 
stovepipe digital situational awareness and command and control systems. To ensure 
interoperability between ground forces, JROC Memorandum 163-04 (JROC, 2004) 
approved the Marine Corps and Army convergence strategy to adapt a single JBFSA 
capability. An incremental approach strategy was adopted to reach SA convergence. Joint 
Capabilities Release (JCR) represents Increment I and is currently being fielded to 
operational units within the Army. Joint efforts are ongoing to develop and test Increment 
II, Joint Battle Command-Platform (JBC-P). Both software packages leverage fielded 
Blue Force Tracker (BFT) hardware and provide enhanced capabilities to address JROC 
convergence directives. 

JCR and JBC-P were designed to coincide within the Army Battle Command 
System (ABCS). As a result, both solutions are more Army centric than Marine Corps 
centric. Consequently, mismatches exist within and beyond the software between the 
Services. The primary challenge for the Marine Corps’ team is marrying the solutions 
with the Marine Air-Ground Task Force (MAGTF) systems and architecture. 
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I. 


INTRODUCTION 


A. JOINT FORCE FUNDAMENTALS OF THE UNITED STATES ARMED 
FORCES 

Joint Publication 1 (Joint Chiefs of Staff, 2007) is the keystone document that 
establishes doctrine for joint operations. The document describes the present-day 
battlefield as ever changing and the United States military’s adaptability to counter its 
adversaries. The document describes the modern-day battlefield as “extremely fluid with 
changing alliances and new threats. The United States military is designed to operate 
seamlessly in that environment, addressing a variety of challenges, both traditional and 
irregular” (Joint Chiefs of Staff, 2007, p. i). The fundamental concept in maintaining the 
advantage against all challengers is fighting as a unified force. The ultimate goal of the 
unified force is to increase the effectiveness and lethality of available military might. The 
Goldwater-Nichols Act of 1986 was instrumental in improving several critical areas 
within the Department of Defense (DoD). One area was focusing the Services from 
independent operations to joint interest operations. One of the key objectives was to 
provide for more efficient use of the DoD’s resources (Goldwater-Nichols Department of 
Defense Reorganization Act, 1986, p. 4). Joint Publication 1 (Joint Chiefs of Staff, 2007) 
describes joint operations as “team warfare.” Consequently, “the synergy that results 
from the operations of joint forces maximizes the capability of the force. The advantage 
of a joint team extends beyond the battlefield and across the range of military operations” 
(Joint Chiefs of Staff, 2007, p. 1-2). 

B. PROBLEM STATEMENT 

The United States military maximizes its combat power by fighting as a joint 

force. However, within the shared battlespace the Services operate stovepipe systems to 

provide tactical situational awareness of their units. These systems are not interoperable, 

which significantly increase the potential for fratricide occurrences. The Marine Corps 

initiated efforts to comply with the Joint Requirements Oversight Council (JROC, 2004) 

convergence directive by altering the fielding strategy of the Data Automated 

Communication Terminal (DACT) variants, which was its primary digital situational 
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awareness/command and control (SA/C2) system. Additionally, in order to communicate 
with Army units sharing the battlespace in support of the Global War on Terrorism 
(GWOT), the Marine Corps rapidly procured and fielded the Army’s SA/C2 solution, 
Force XXI Battle Command Brigade and Below—Blue Force Tracker (FBCB2-BFT). 
Consequently, the Marine Corps relies on the Army’s infrastructure and resources to 
operate the systems. The Army maintains the L-Band satellite network, architecture, and 
resources required to operate FBCB2-BFT within the current Global War on Terrorism 
(GWOT) region. However, the resources are limited outside that region and may be 
unavailable for Marine forces conducting traditional expeditionary missions. Moreover, 
the planned upgrade to the FBCB2 system, designated as Joint Capability Release (JCR), 
represents Increment I towards interoperability, but its software and hardware capabilities 
have not proven fully capable of meeting Marine Corps operational requirements. 
Additionally, reasonable concerns exist in developing, testing, and concept of 
employment (COE) for Increment II, Joint Battle Command-Platform (JBC-P). Both 
enhanced capabilities are essentially designed towards the Army Battle Command 
System (ABCS). They mandate an overly complex architecture that is dependent on 
organic ABCS resources that do not reside within the Marine Air-Ground Task Force 
(MAGTF) architecture. Furthermore, testing revealed an overarching lack of a reliable 
network for SA/C2. 

C. PURPOSE 

The purpose of the thesis is to provide an analysis of Marine Corps efforts to 
comply with the JROC convergence directive for a Joint Blue Force Situational 
Awareness (JBFSA) capability for ground forces. The Army’s FBCB2-BFT solution was 
first fielded to Marine Corps units during preparation for Operation Iraqi Freedom. Since 
that time, the system has been widely fielded throughout the Marine Corps. The system 
has clearly been a force multiplier in the combat zone and as a result the Marine Corps 
SA program of record, DACT, has been deemed obsolete by leadership. 

This research provides insight into the actions taken by the Marine Corps towards 
convergence. This research highlights complexities of this joint effort, to include 
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imbalance in resources, priorities, and capabilities between the Army and Marine Corps. 
Additionally, this research provides some considerations and recommendations for 
further study. 

D. RESEARCH QUESTION 

The primary intent of the JROC is to reduce redundancy and increase 
commonality between the Services. This research will address the primary question; why 
are the current convergence efforts not as favorable towards Marine Corps 
implementation as the Army? In addition, how important is it for all players to have 
equal influential power and resources on joint efforts? 

E. METHODOLOGY 

The Marine Corps and Army have separate requirements documents for their 
respective digital SA/C2 systems. These requirements and corresponding parameters 
were used to evaluate the initial new capability, which proved to be impractical. An 
endeavor was undertaken to develop a joint Capabilities Development Document (CDD) 
for the objective solution. The research methodology focuses on evaluating the directive 
to develop and field a JBFSA capability at all echelons. This was accomplished through a 
quantitative content analysis of program-related materials. Data collection was achieved 
via confidential in-person interviews with personnel from the Army and Marine Corps 
program offices. The interviews were conducted at the individual program office site and 
were recorded, transcribed, and then analyzed for relevance and accuracy. The 
participants interviewed provided adequate factual information on the history and 
ongoing efforts, but opinions were not solicited. Additional data was collected through 
analysis of test reports. Joint Capabilities Integration and Development System 
documents, and other related program documents for amplifying information. 
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F. ORGANIZATION OF THE THESIS 

Chapter II, Background, provides a brief history of the Services’ specific digital 
SA capabilities, oversight council directives that initiated Marine Corps involvement with 
the Army’s platform and dismounted SA solution, and the Marine Corps’ Blue Force 
Tracker Family of Systems program. 

Chapter III examines the incremental approach to reach SA convergence. It also 
provides analysis of each increment’s capabilities and test and evaluation efforts. 

Chapter IV provides considerations from the analysis of Increment I and 
Increment II. 

Chapter V provides recommendations for further research to better determine 
Increment II feasibility of fielding to the Marine Corps and analysis of Blue Force 
Tracker use in Marine Corps expeditionary operations other than war. 
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II. BACKGROUND 


This chapter provides a brief history of the Services’ specific digital SA 
capabilities, the oversight council directives that initiated Marine Corps involvement with 
the Army’s platform and dismounted SA solution, and the Marine Corps’ Blue Force 
Tracker Family of Systems program. 

The U.S. Marine Corps and Army have traditionally employed diverse, friendly 
force tracking capabilities to enhance their respective battlefield situational awareness. At 
the onset of Operation Iraqi Freedom (OIF), a number of stovepipe systems were 
operated by each Service. The various systems were extremely reliable and effective but 
not interoperable. Each system transmitted its respective form of position/location 
information (PLI) data to the joint task force level, via the Joint Global Command and 
Control System (GCCS-J) server, which then populated the higher echelon common 
operating picture (COP). At the lower echelon, the Marine Corps used Command and 
Control Personal Computer (C2PC) and the Army used Maneuver Control System-Light 
(MCS-L) 1 to display the COP (Stengrim, 2005, p. 4). The systems were incapable of 
sharing information directly due to different architectures (Stengrim, 2005, p. 4). 

A. MARINE CORPS DIGITAL SITUATIONAL AWARENESS AND 

COMMAND AND CONTROL CAPABILITIES 

At the initial stage of OIF, DACT and the Miniature Transmitter (MTX) were the 
primary digital SA/C2 tactical systems employed by Marine forces. 

The DACT is the Marine Corps’ program of record for tactical Blue Force 
tracking and situational awareness. DACT provides a two-way path (send and receive) 
for PLI, messaging, and chat. The DACT operates on the Enhanced Position Location 
Reporting System (EPLRS) classified network that is limited to line-of-sight (LOS) 
terrestrial transmission. The DACT capability was fielded as vehicle-mounted (M- 
DACT) and hand-held dismounted (D-DACT) variants. The following are excerpts from 
the DACT Operational Requirements Document (ORD) Change 3 (Marine Corps Combat 
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Development Command, 2001), signed January 8, 2001, that explains the requirements, 
key performance parameters (KPP), and related operational parameters for the system. 


The DACT shall provide automated communications support for 
commanders in tactical operations. This automation expedites existing 
manual decision-making and executing processes, in addition to the 
processes associated with planning, processing combat information, and 
the exercise of tactical direction. The DACT will be used to transmit, 
receive, store, retrieve, create, modify, and display map overlays and 
commanders’ critical information requirements (CCIRs). The DACT will 
exchange this information with other users of the Tactical Data Network 
(TDN). Other units’ positions, coordinates of user-designated points, pre¬ 
formatted messages and free-text information are CCIRs managed by the 
DACT. Tactical communications such as radio network and local area 
networks (LANs) will be the systems that enable DACT generated data to 
be transmitted between users. Using global positioning information, and 
digital maps resident on the removable disk, the DACT will provide a 
screen display of its own position location, (p. 1) ... 

The KPPs for the DACT consist of the ability to display a map with GPS 
derived position location information (PLI) [Interoperability KPP] 
represented on the map, the ability to transmit PLI generated by the DACT 
to a C2PC Gateway and receive PLI from a C2PC Gateway, and transmit 
and receive those messages in Appendix D. The dismounted DACT shall 
be interoperable with UHF, VHP and HP voice/data radios that are man- 
portable and mounted in tactical/armored vehicles. This maintains the 
requirement to exchange preformatted and free text messages on point-to- 
point and netted doctrinal radio nets. (Marine Corps Combat Development 
Command, 2001, p. 3) 

The DACT-generated PLI data is transmitted to GCCS-J by the Intelligence and 
Operations Workstation (lOW) functioning as a C2PC Gateway located in the 
commander’s Combat Operations Center (COC). Figure 1 depicts the DACT System 
Interface Diagram. 
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Figure 1. DACT System Interface Diagram (From Marine Corps Combat Development 

Command, 2001, p. 34) 

The MTX is a beacon limited to one-way communication that provides the 
capability to identify position and track progress (Stengrim, 2005, p. 5). The MTX 
primarily supported Marine Corps Special Operations Command ground forces. 
However, a limited number of devices were provided to the Marine Aircraft Wing 
(MAW) to support rotary platforms operating in the theater of operations. The device 
transmits PLI only; it has no messaging function. The position information generated by 
devices mounted on air assets was pushed to the Marine Tactical Air Command Center 
(TACC) via C2PC. The MAW operated the MTX as a short-term solution until the 
Aviation BFT fielding. 
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The DACT and MTX limitations disqualified both systems as viable solutions 
towards JBFSA. Only a limited number of Marine Corps forces had either capability at 
the onset of OIF. Figure 2 depicts M-DACT, D-DACT, and MTX systems. 



MTX 


Figure 2. M-DACT, D-DACT, and MTX Systems (From Product Manager, Digital 

Fires Situational Awareness [DFSA], 2010) 

B. U.S. ARMY FBCB2-BFT 

The Army’s program of record for digital Blue Force tracking and situational 
awareness is FBCB2. FBCB2 provides a two-way (send/receive) path for PLI and is 
messaging and chat capable. FBCB2 was developed in two different versions to utilize 
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available EPLRS and L-Band satellite networks, FBCB2-EPLRS and FBCB2-BFT, 
respectively. The E-Band network enables flexible and beyond-line-of-sight 
communications. The satellite network utilizes commercial encryption. Consequently, 
FBCB2 has a National Security Agency-approved classification of sensitive but 
unclassified. The FBCB2 Program Management Office (PMO) is a component of the 
Program Executive Office Command Control and Communications Tactical (PEO C3T). 
EBCB2-BET is a multi-Service, Army Acquisition Category 1C, post-Milestone C 
program. 

The remainder of this section relies heavily on Conatser and Grizio’s (2005) 
Master of Business Administration professional report. The report provides a 
comprehensive analysis on the genesis, history, and employment of FBCB2 within the 
Army. 

The FBCB2 capabilities had a modest beginning. 


In 2000, the Balkan Digitization Initiative effort in both Bosnia and 
Kosovo was the genesis for BET. About 600 systems had been used with 
the commercial Eieldworks/Kontron and Ku Band using a reduced 
functionality EBCB2 software Version 3.1. The maturity level of FBCB2 
software provided an effective Graphic User Interface (GUI), a variety of 
functional command and control messaging capabilities, a robust mapping 
capability, graphic control measure development and symbology. Finally, 
hardware development under the FBCB2 program baseline and 
procurement under Eow Rate Initial Production (ERIP) provided a partial 
hardware solution to install. The ability to leverage E-Band transceivers 
from a pre-existing Movement Tracking System contract was the final 
hardware component required to complete the system, (p. 35) 

The FBCB2 system was battle tested, which led to follow-on deployment in 
support of Global War on Terrorism. 

The initiative that culminated with the development and fielding of the 
FBCB2-BFT system actually evolved over time and was one of three 
technical initiatives to increase command and control in the theater of 
operations. The broad effort to support United States Central Command 
(CENTCOM) began in February 2002, and was threefold, as follows: 1) 

Correct current communications and network problems within the theater 
of operations, 2) Design and build a command center for the integration of 
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all fielded ABCS Systems, and 3) Field 200 “tracking systems” within the 
Afghanistan theater of operations. (Conatser & Grizio, 2005, p. 33) 

System fielding to combat units in support of Global War on Terrorism operations 
was expedited. Leadership realized it was vital for some level of commonality between 
the multinational force to increase SA and reduce the occurrences of friendly fire. 
Additionally, FBCB2 increased combat efficiency. 

The 2d Brigade Combat Team (BCT), 3d Infantry Division (ID) was 
deployed to Kuwait in September and October 2002 for Operation Desert 
Spring (formerly Intrinsic Action) and was the first unit to receive 
FBCB2-BFT. What followed was an unprecedented fielding of FBCB2- 
BFT systems in Army Pre-positioned Stocks (APS) and unit platforms in 
theater, as well as on unit platforms at home station prior to their 
deployment. This resulted in simultaneous installation of more than 1,000 
systems on three continents, spanning six countries, including 20 states 
within the United States, and involving more than a dozen Army, Joint, 
and Coalition formations. Throughout this process, over 4,000 soldiers 
were trained. The system was provided to the 3d ID (M); 1st Armored 
Division; lOIst Air Assault Division; 82d Airborne Division; 2d Light 
Cavalry Regiment; 3d Armored Cavalry Regiment; 173d Airborne 
Brigade; 3d Brigade, 4th ID (M); 75th Exploitation Task Force; 11th 
Aviation Brigade; 12th Aviation Brigade; 1st Marine Expeditionary Eorce 
(MEE); and the 1st United Kingdom Armored Division, as well as selected 
V Corps and Coalition Eorces Eand Component Command (CEECC) 
platforms and command posts, (p. 38) ... 

EBCB2-BET provided Operation Enduring Ereedom and Iraqi Ereedom 
commanders and units a remarkable capability that greatly enhanced their 
combat effectiveness. EBCB2-BET enabled the ability to navigate under 
limited visibility conditions, to move rapidly over great distances and 
synchronize unit movement, and to communicate both vertically and 
horizontally over extended distances. Unit Commanders’ initial 
confidence in the system varied. It is difficult to embrace a new system 
and discard tried and true practices with which they and their units were 
familiar and confident. In some cases, units were forced to accept, and 
came to rely on, EBCB2-BET when traditional equipment and accepted 
practices proved insufficient during the campaign. During Operations 
Enduring Ereedom and Iraqi Ereedom, the level of EBCB2-BET’s 
effectiveness and individual unit “digital learning curves” varied after 
receiving the system. Units that quickly embraced the new technology and 
placed command emphasis on its training and employment, benefited early 
on in the campaign. Others that either received the capability late in the 
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fielding process or did not quickly embrace it, were forced to adjust during 
the conflict. (Conatser & Grizio, 2005, p. 41) 

The Army strategically fielded the FBCB2-BFT variant, as compared to the 
EPLRS variant, in greater numbers among its tactical combat units in Iraqi and 
Afghanistan. Army senior leadership understood the scope of the operating area and the 
nature of the environment in which GWOT operations would predominantly take place. 
Combat operations would be conducted in austere, restricted, and vast areas where 
combat units would exceed the LOS limits of the EPLRS network. Satellite 
communications are not limited to the same restrictions of the EPLRS network. Both 
EBCB2 variants were mounted exclusively on High Mobility Multipurpose Wheeled 
Vehicle (HMMWV) platforms. 

1. FBCB2 Architecture 

The Network Operations Center (NOG) is the central point in the EBCB2 
network. EBCB2-generated digital data is pushed to the NOG via L-Band Satellite and 
ground station. The NOG integrates and disseminates to all active BET systems via 
reverse path. EBCB2 uses commercial type encryption. Consequently, the network is a 
one-way feed to the joint environment. EBCB2 PEI is transmitted to GCCS-J through a 
radiant mercury guard located at the NOG. Marine Corps COG pull data from GCCS-J 
via JTCW. Marine Corps PEI is classified and cannot transmit to EBCB2. The radiant 
mercury guard is there to prohibit secret information from passing to the network. Eigure 
3 depicts the EBCB2 data flow. 
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C. OVERSIGHT COUNCIL DIRECTIVES 

Fratricide has always existed on the battlefield. Studies have shown that 

technological advances have significantly reduced occurrences. In the initial stages of 

OIF, fratricide accounted for about 11% of United States battlefield deaths, as compared 

to 24% during Desert Storm over a decade earlier (Cahlink, 2004). It was widely 

understood that the lack of battlefield SA was a major factor for the occurrences. In June 

2003, the JROC ordered the development of the framework to enhance combat 

effectiveness and improve interoperability between the ground forces (JROC, 2003). 

JROC Memorandum (JROCM) 161-03 (JROC, 2003) requested the Army and USMC 

provide an integrated briefing to the JROC discussing the way ahead towards converging 

efforts for achieving a single Joint capability. In 2004, to ensure interoperability between 

the Army and USMC, JROCM 163-04 (JROC, 2004) approved the Marine Corps and 

Army convergence plan to adapt a single capability. The JROC approved the plan to 

make FBCB2 the capability baseline, assigned the U.S. Army as the lead Service to 
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develop the JBFSA capability, and directed the Marine Corps to adopt FBCB2-BFT for 
its platform and dismounted applications (JROC, 2004). Marine Requirements Oversight 
Council (MROC) Decision Memorandum (DM) 41-2004 (MROC, 2004), dated June 2, 
2004, establishes the MROC concurrence with the recommendation to migrate to the 
FBCB2 baseline as the Marine Corps refreshes its dismounted and mounted devices. 
However, the MROC desired for the Marine Corps to “remain independent and maintain 
its own communication architecture” (MROC, 2004). 

D. MARINE CORPS AND FBCB2-BFT 

In late 2002, Marine Corps and Army tactical units had limited methods to readily 
communicate with each other. To prepare for OIF, I Marine Expeditionary Force 
submitted an Urgent Universal Needs Statement (UUNS) to acquire 50 vehicle-mounted 
FBCB2-BFT systems to communicate with Army ground units sharing the battlespace. 
The units immediately recognized the advantages of the FBCB2-BFT capability as a 
force multiplier. Marine forces’ operational requirement for FBCB2-BFT rose 
significantly after the onset of the GWOT. The system provided maneuver forces with the 
ability to communicate and exchange critical combat information and messages with 
adjacent units utilizing same system. Subsequent to the initial UUNS, 
MARCORSYSCOM responded to multiple UUNS and initiatives requesting FBCB2- 
BFTs for deployed units. 

• March 2003, UUNS requested 267 systems to support convoy operations. 

• January 2004, UUNS requested 100 systems to directly support combat 
operations. 

• September 2004, UUNS requested 26 systems to directly support combat 
operations. 

• FY05 Supplemental Initiative, to procure 2600 systems to mitigate 
shortfalls of forces supporting GWOT. 

• FY05 Marine Corps Forces Central Command (MARCENT) requirement, 
requested 1826 systems as part of a multisystem integrated effort for 
Ml 114 HMMWVs supporting OIE. 
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In November 2008, representatives from the BFT PMO and support contractors 
deployed to locations in Kuwait and Afghanistan to conduct a field assessment of the 
Marine Corps’ BFT effort in support of Operation Enduring Freedom (OEF) ramp up. 
The objective of the trip was to improve the logistical and operational support to Marine 
forces. The assessment concluded that the Marine Corps was a burden on the Army’s in¬ 
theater contracted logistical support network and continued support was unsustainable for 
the long term. A Marine Corps BET Service Center was established in Kuwait to support 
MARCENT combat requirements for both the Iraq and Afghanistan theaters. 
Additionally, all BET-equipped vehicles transitioning from Iraq to Afghanistan were 
refurbished at the service center in order to upgrade the combat strained systems. 
Moreover, plans were coordinated with stakeholders, including Marine Corps Eogistic 
Command, to establish BET Eield Service Representative (ESR) sites onboard Camp 
Kandahar, Camp Eeathemeck, and follow-on forward operating bases. 

At the height of combat operations, the Marine Corps had 19 dedicated BET 
ESRs. The ESRs were strategically positioned aboard each major Marine Corps operating 
base within theater and in the continental United States (CONUS). The ESR conducted 
maintenance, installations, and over-the-shoulder training to all Marine Corps units 
utilizing BET systems. 

1. Memorandum of Agreement with Stakeholders 

A Department of the Army memorandum of agreement (MOA; Department of the 
Army, Program Executive Office Command, Control, and Communications Tactical 
[PEO C3T], 2004) between the Army, the Marine Corps, and the United States Special 
Operations Command (USSOCOM) “established an enduring partnership among the 
Services and solidified the roles directed by the JROC for achieving a single, joint 
capability” (p. 2). Additionally, the MOA recognized program Manager (PM), PBCB2 as 
servicing agency and allowed the Marine Corps access to existing Army contracts to 
procure and support PBCB2-BPT. The Army was able to economically procure PBCB2- 
BET systems and services by combining the requirements of all Services and 
subsequently purchasing in economically advantageous quantities. The result was a 
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decrease in the per-unit cost and substantial savings to the government, savings that could 
not have been realized through smaller purchases made independently. Both the Army 
and the Marine Corps realized cost avoidance by combining their respective FBCB2-BFT 
system requirements, enabling both Services to benefit from the quantity discounts 
provided in Army contracts. Moreover, each saved additional funds by conducting joint 
system integration and testing and combining logistical services support, thereby 
avoiding the cost duplication that inevitably occurs when like items are procured 
separately. More important, utilizing already established Army contract vehicles enabled 
the Marine Corp to efficiently and expeditiously meet its FBCB2-BFT requirements in 
support of home station training and overseas contingency operations. 

2. Marine Corps BFT Program Management Office 

For the Marine Corps, the FBCB2-BFT capabilities are referred to as the BFT 
Family of Systems (FoS). The BFT FoS is a product line within the JBC-P FoS portfolio. 
The JBC-P FoS is defined as a weapon system program with a product line made up of 
systems and products associated with the BFT FoS (Increment I) and JBC-P (Increment 
II). The PMO resides within MARCORSYSCOM. The BFT FoS is the primary digitized 
battlefield COP component of the Marine Air-Ground Task Force (MAGTF) C2 
infrastructure for echelons below the battalion level. The BFT FoS is comprised of the 
vehicle-mounted BFT, the dismounted Tactical Operations Center (TOC) Kit, and 
FBCB2 software. In addition to the systems procured and delivered in support of GWOT, 
to date the BFT PMO has procured 4,000 FBCB2-BFT systems. Supporting combat zone 
requirements is a priority, but the PMO made the BFT FoS readily available to all Marine 
Corps units in CONUS, Hawaii, and Okinawa. The systems supported home station 
readiness and pre-deployment training requirements. Figure 4 depicts the BFT FoS 
systems. 
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Figure 4. TOC Kit and HMMWV Mounted BFT (From Product Manager, DFSA, 2008 

a. Blue Force Tracker 

The BFT system consists of the JV-5 computer, 12-inch display, 
interconnecting cables, MT-2011 series L-Band satellite transceiver, a Defense Advanced 
Global Positioning System Receiver (DAGR), and an installation kit appropriate to the 
host vehicle type. The Deputy Commandant (DC), Combat Development and Integration 
(CD&I; 2007) Letter of Clarification (LOC) established the interim procurement BFT 
objective at 8,549. The objective was based on emerging requirements and to support the 
Marine Corps’ convergence strategy (CD&I, 2007). In both OIF and OFF theaters, BFT 
systems were installed on various platforms, including the HMMWW family of vehicles 
(FoV), Light Armored Vehicle FoV, Medium Tactical Vehicle Replacement, Logistics 
Vehicle System Replacement, and M88 Recovery Vehicle. Figure 5 depicts the BFT core 
components. 
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Figure 5. BFT Core Components (From Produet Manager, DFSA, 2008) 


b. Tactical Operations Center Kit 

The TOC Kit is the BFT variant that brings blue force SA capability into 
the MAGTF COC. The TOC Kit consists of a CF-30 laptop, MT-2011, DAGR, and 
interconnecting cables. The DC, CD&I LOC (2007) established the interim procurement 
TOC Kit objective at 562. 

c. FBCB2 Software 

The FBCB2 software is the initial baseline software that enables ground 
units to exchange large volumes of C2, SA, and PLI. Additionally, the software enables 
operators to send and receive C2 messages and overlays. The current fielded version is 
FBCB2 6.5. 
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E. SUMMARY 


This chapter provided the reader with background information on Marine Corps 
and Army specific digital SA capabilities and the oversight council directives that 
mandated convergence. 
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III. INCREMENTAL APPROACH 


This chapter will describe the incremental approach strategy to achieve SA convergence. 
Additionally, it will provide an analysis of each increment’s capabilities and test and 
evaluation efforts. 

A. INCREMENT I—JOINT CAPABILITIES RELEASE 

I. Overview 

JCR is the upgrade to the FBCB2 system. The software developer is Northrop 
Grumman, in Carson, CA. Initial fielding of FBCB2 occurred over a decade ago, but this 
rugged system still remains the primary digital battlefield tactical SA/C2 solution. JCR 
brings enhanced capabilities that are force multipliers to the warfighter: Two of these 
capabilities address critical issues that exist in the current system; latency and 
information security. The improved capabilities include a new transceiver to support a 
high-speed satellite communications network and a programmable in-line encryption 
device that supports Type 1 data encryption. The PM FBCB2 JCR Test and Evaluation 
Strategy briefing (U.S. Army Office of the Program Manager, FBCB2 [PM FBCB2], 
2010) states that the software’s primary purpose is to “allow forces to simultaneously 
mount, execute, and recover from operations and synchronize all of the operating 
systems” (p. 8). Additionally, the briefing states JCR improves C2 “while on the move by 
receiving and updating the situation awareness via net-centric linkages between Tactical 
Operational Centers (TOCs) and net-centric links between mounted and future JBC-P 
systems” (PM FBCB2, 2010, p. 8). In fiscal year (FY) 2011, the Army began fielding 
JCR to operational units in CONUS and in the Republic of Korea. The Marine Corps will 
begin fielding to units during their pre-deployment training, in the third quarter of 
FY2013. The JCR software version 1.3.1.4 is the official Marine Corps’ fielding 
candidate. Moreover, JCR represents the interim solution (Increment I) towards JROC- 
directed SA convergence. 
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2. Capabilities 

a. BFT 2 Network/Transceiver 

The new faster satellite network is known as BFT 2. The current system is 
plagued with latency and its transceiver is half-duplexed. Consequently, friendly position 
updates take minutes and send/receive messages are limited to single transmission (one 
way at a time). The BFT 2 network provides 10 times the bandwidth as compared to the 
existing network. The new transceiver is full-duplex and enables simultaneous 
send/receive transmissions. With its enhanced capabilities, the system is capable of 
updating friendly positions and transmits messages in seconds. Therefore, the warfighter 
will be able to share more vital battlefield information to more users and do it faster. 
Additionally, the increased data capacity improves the accuracy of friendly SA and the 
depiction of reported enemy locations, obstacles, and known battlefield hazards. The 
following excerpt is from the BFT 2 PowerPoint (PM FBCB2, 2011) brief that provides 
more details on BFT 2. 

The BFT 2 upgrade program will enhance performance for BFT 
transceivers in both the ground and air domains. The next generation BFT 
2 network provides near global coverage (70°N to 70°S) and operates over 
geosynchronous L-Band satellites (e.g., Inmarsat-3, Inmarsat-4, Artemis, 
and Thuraya). The BFT2 network consists of two active and one backup 
Satellite Network Control Centers (SNCC), up to eight (8) Satellite 
Ground Stations (SGS), and supports up to 200,000 remote Ground 
Vehicular Transceivers and Aviation Transceivers. Each SNCC connects 
with the SGSs through a redundant terrestrial/Very Small Aperture 
Terminals (VSAT) network. A SGS interoperates with BFT-2 
Transceivers in a star topology. A BFT 2 air interface designed to meet 
capacity and latency requirements allows the SGS and BFT 2 Transceivers 
to exchange Joint Variable Message Format. (PM FBCB2, 2011, p. 3) 

b. KGV-72 Encryption Device 

The KGV-72 is a new programmable in-line encryption device (PIED) 
that encrypts BET-generated data Type I, under the classification “secret.” The device 
resides between the system processor and GPS transceiver. The KGV-72 is the solution 
to provide the warfighter a seamless, classified network. Additionally, the KGV-72 
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abides by JROC policy for classified friendly battlefield information (JROCM 071-08) 
and National Security Agency Type 1 certification requirements. 


c. Additional Capabilities 

JCR provides an abundance of additional capabilities to BFT operators. 
The following list of capabilities was gained from in-person interviews with PM FBCB2 
senior leadership and a PowerPoint brief provided by the PMO (Program Office, FBCB2, 
2010 ). 


• Marine Corps EPLRS Interoperability—provides Marine Corps 
network with a terrestrial capability 

• JCR Logistics (Log; C2/SA Interoperability)—allows exchange of 
C2/SA between JCR Log and JCR Vehicle 

• C2 Repository (C2R)—server that allows use of the Address Book 
Database 

• Self-Descriptive SA (SDSA)—removes requirement for large 
preplanned databases and allows users to log in and send an SDSA 
message with all necessary information (i.e., Unit Reference 
Number, Internet Protocol address) to update C2R. Allows BLT- 
equipped units to change task organizations in the field to meet 
new mission requirements 

• Recognition of Combat Vehicles—allows recognition of combat 
vehicles training tool 

• Graphical User Interface/Commercial Joint Mapping Toolkit— 
permits new map types 

• Data Dissemination Service (DDS)—allows data flow to GCCS-J 

• Secure Mission Data Loader (MDL)—provides encryption of data 
on MDL, connects to Windows and Linux 

• Slew-to-cue—allows JCR operator to auto send message to 
Vehicle Commander for shoot/no shoot determination 

• Open Office—allows writer, calculations and impress applications 
on system, compatible with Microsoft Office 

• Personal Pile Polder—allows for easy file management 

• Enhanced Imagery—allows images to be sent/received 

• CENTCOM Regional Intelligence Exchange System International 
Security Assistance Porce—allows exchange of data with coalition 
forces in Afghanistan 
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3. 


Architecture 


The JCR network architecture is complex. The Network Operations Center 
(NOC) remains the backup node to data flow. Three NOCs are geographically segmented 
for redundancy. Redundancy is built in the network for seamless transition from one 
NOC to another, in the event one is degraded. Celestial JCR-generated PLI and messages 
are the same as the current FBCB2-BFT. Data are pushed to the NOC via L-Band 
Satellite and ground station. The NOC integrates and disseminates to all celestial JCR 
systems via reverse path. There are two new systems required with JCR, the DDS server, 
and C2R. C2R enables SDSA and DDS enables interoperability to the joint community. 
The DDS located in the NOC (NOC DDS) distributes to another DDS server located in 
the Combatant Command (COCOM) TOC. The DDS at the COCOM pushes to GCCS-A, 
which continues the path to GCCS-J, and then to the MAGTF architecture. The data flow 
reverses for terrestrial data generated via Marine Corps systems. The data flow is 
seamless with the new BFT 2 network and occurs in a matter of seconds. Figure 6 depicts 
the JCR data flow. Figure 7 depicts the JCR concept of employment. 
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Figure 6. JCR Data Flow (From Product Manager, DFSA, 2010) 
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Figure 7. JCR Concept of Employment (From Product Manager, DFSA, 2010) 
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4. 


Test and Evaluation 


This section relies heavily on in-person interviews with the JBC-P FoS PMO 
leadership and SPAWAR test result documents. 

The Marine Corps joined the Army’s JCR test paradigm in FY2005. Since that 
time, JCR underwent an intensive test and evaluation (T&E) process. The Marine Corps’ 
test strategy is aligned with the Army’s. Joint test events are conducted to maximize 
resources and better assess mutual requirements. When necessary, the Marine Corps 
team conducts independent testing for specific Marine Corps requirements. The JBC-P 
FoS PMO established three mutually supported sites with dedicated personnel to 
assess each JCR software build. A limited Initial Test Team (ITT) augmented the Army’s 
test team, which was collocated with the software developer Northrop Grumman. 
This ITT’s primary mission was to test Marine Corps specific requirements in each 
software release. More comprehensive teams are located in Charleston, SC, within the 
Space and Naval Warfare Systems Center (SPAWAR) Atlantic and aboard Marine 
Corps Base (MCB) Camp Pendleton, CA, within the Marine Corps Tactical Systems 
Support Activity (MCTSSA). The SPAWAR facility is the Marine Corps’ JBC-P 
FoS Increment I Configuration Manager (CM). MCTSSA is a component of 
MARCORSYSCOM. The MARCORSYSCOM webpage identifies MCTSSA as the 
Marine Corps “organization for integration, interoperability, and technical support for 
tactical Command, Control, Communication, Computer, and Intelligence (C4I) systems” 
(marcorsyscom.marines.mil). Both sites are tasked with conducting all Increment I and 
Increment II development testing efforts. 

a. Requirements 

The DACT Operational Requirements Document (ORD; Marine Corps 
Combat Development Command, 2001) and direction from DC, CD&I were the basis for 
the requirements and parameters used to evaluate JCR: 

• System shall display 100% SA (PLI) accuracy within a 15-minute 
window (based on refresh rate); 

• System shall send/receive messages within 5 minutes; 
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• Systems will demonstrate the ability to display a map with GPS- 
derived PLI represented; 

• System must transmit/receive PLI data with C2PC Gateway 
(shows interoperability with Joint Taetieal COP Workstation 
[JTCW]); and 

• System must transmit and reeeive preform Variable Message 
Format (VMF) messages. 

b. Events 

Eaeh software version and subsequent release underwent identieal series 
of joint test events. System Subsystem Aceeptanee Testing (SSAT) is the first in the test 
series. SSAT is a formal lab aceeptanee test of the software. SSAT is conducted to verify 
the ability of the software to meet system requirements and readiness for formal testing 
(PM FBCB2, 2011). The developer formally delivered to the government each JCR 
software release to the ITT. The ITT conducted all SSATs within controlled spaces at the 
developer facility. After successful completion of the SSAT, the software build was sent 
to the Central Testing Support Facility (CSTF), Fort Hood, TX. The CTSF then built the 
Marine Corps’ hard disk, referred to as the gold brick. The gold brick was then sent to the 
SPAWAR facility. 

Risk Reduction Event (RRE) is second in the test series. The purpose of the RRE 
was to verify and validate the JCR capabilities’ functionality in the planned Marine 
Corps/Army architecture. The RREs were conducted at both comprehensive test sites. 
The Army tested out of the CSTE. The RREs were executed in four phases, in numerical 
order. Phases I and II were performed at SPAWAR. When the initial phases were 
completed, multiple hard disks were duplicated and sent to MCTSSA for subsequent 
testing. Phases III and IV were simultaneously executed by both test sites and the CTSE, 
utilizing the Defense and Research Engineering Network (DREN). The DREN supports 
DoD-wide research, development, testing, and evaluation activities. The vast majority of 
DT events were completed on the DREN. During each phase, data were collected on the 
interactions between the architectures, overall system performance, and compliance with 
the DACT ORD requirements. In addition. Phase I, II, and III tests are completed to 
check hardware functions, system configuration, and standalone operations. Moreover, 
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Phase III and IV tests are performed to verify the system can accurately transmit and 
receive data throughout a Marine Corps representative network. All phases were 
performed on the BFT FoS loaded with JCR software, to verify the software satisfied the 
testable software requirements set forth in the DACT ORD (Marine Corps Combat 
Development Command, 2001). Test cases were developed using specific DACT ORD 
requirements to evaluate the system to support each test phase. Each test case was 
completed and assessed with pass, pass with exception, or fail (SPAWAR, Atlantic, 
2011, p. 3). Only after successful completion of each RRE would the software move to a 
formal field test (ET) or field user evaluation (EUE). 

Appendix A is an excerpt of RRE test cases from the SPAWAR RRE 9 Test 
Report (SPAWAR, Atlantic, 2011). Included is the attribute support for the specific 
DACT ORD Capability and the criteria used to assess each attribute. 

At the completion of each test day, a meeting, referred to as a hotwash, was 
conducted with all test participants. The hotwash discussed issues encountered including 
test case discrepancies and other software and system deficiencies. A consolidated list 
was generated, evaluated, and prioritized based on severity. The list was provided to the 
software developer as a Software Change Request (SCR). The developer normally would 
release a software patch to adjudicate the SCRs. SCR fixes that could not be resolved 
with a patch would be included in a follow-on software release, engineered to address the 
deferred SCR fixes. 

Third on the test series, and more often accomplished concurrently and 

throughout DT, were the Joint Interoperability Test Command (JITC) certification 

(combined Army and USMC certification) and risk assessment. The JTIC certification 

process was accomplished by representatives from the Defense Information Systems 

Agency (DISA). The certification not only included an evaluation of information 

exchanges and the interfaces used to support those exchanges, but also included the 

JITC’s evaluation of the elements of the Net Ready KPP (PM PBCB2, 2011, p. 3-2). The 

JTIC evaluation was based upon requirements identified in the JCR Information Support 

Plan (ISP) and Interoperability Certification Evaluation Plan (ICEP). The risk 

assessments were comprised of the information assurance (lA) requirements. The JBC-P 
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Test and Evaluation Master Plan (TEMP) describes the assessments as “designed to 
reduce the risks due to the threat of computer network attack. Software vulnerabilities 
and poor system configuration constitute avenues for unauthorized access to the system, 
manipulation or theft of data, and denial of service” (PM PBCB2, 2011, p. 3-2). 

Eield Test (ET) is a joint event using limited resources. The Marine Corps Test 
Team supported each ET in the controlled lab spaces of each test site with desktop 
systems and test support contractors. The Army executed each ET with support 
contractors and soldiers. 

The Marine Corps and Army conducted specific DT events to evaluate JCR. The 
Army changed the way it evaluated and test networked capabilities for the ABCS. 
Network Integration Events (NIE) are a semi-annual combined evaluation of systems that 
will be coupled and fielded to soldiers as part of a capability set: These events were 
aimed to reduce the amount of time and number of resources necessary to field the 
systems. The Army states that the NIE “assesses potential network capabilities in a robust 
operational environment to determine whether they perform as needed, conform to the 
network architecture and are interoperable with existing systems” (bctmod.army.mil). 

Eield User Evaluations (EUE) is specific to the Marine Corps test strategy and 
normally executed concurrently with the NIE. The EUE were limited in scope and 
resources, but they included Marines operating JCR-equipped fixed and vehicle-mounted 
BET systems. The Marines were formally trained and individually filled C2 roles in the 
Marine Division. The EUEs were executed in simulated operational settings (training 
areas) aboard MCB Camp Pendleton. Scenarios were developed and executed under the 
supervision of a test director (Marine Corps infantry field grade officer). The scenarios 
reflected real operational situations to validate system capabilities and interoperability. At 
the conclusion of each EUE, the Marines provided vital feedback via surveys and 
questionnaires. Moreover, the Marine Corps used a EUE for an operational assessment of 
the JCR capabilities. 

Additionally, the Army team conducted events similar to the scope of an EUE, 
called Customer Test (CT) and Eimited User Test (EUT). Each event utilized various 
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numbers of soldiers, test personnel, and fixed/mounted systems. The Army relied on its 
LUTs for an operational assessment of the JCR eapabilities towards fielding. The JBC-P 
FoS PMO eondueted an FUE in eonjunetion with eaeh Army CT/LUT. The normal 
sequenee of tests to evaluate JCR was SSAT, RRE, JITC/risk assessment, and then 
EUE/EUT/CT/ET/NIE (dependent on the seope of the operating foree support and test 
objeetive). 


c. Results 

The Marine Corps formally began JCR testing in August 2009 during 
RRE5. Statisties were kept on C2 (message eompletion/transmits) and SA (PEI sharing 
with the Joint COP). Pereentages were ealeulated based on time available divided by total 
test time. Eigure 8 depiets the C2/SA results for all Marine Corps test events. Test results 
were not initially favorable for a number of reasons. 

• The software did not support the desired level of Marine Corps 
requirements. As a result, the vast majority of the priority SCRs 
generated at eaeh hotwash was Marine Corps related. 

• C2R did not support the eoneept of operations developed to injeet 
Marine Corps address book data in the Taetieal Data 
Communieations Network (TDCN) environment. The team had a 
10% sueeess rate. 

• VME was ineompatible with JTCW. 

• Unlike the Marine Corps, the Army did not evaluate JCR 
independently. Eaeh event, other than SSATs, was a multisystem 
(with multiple PMOs) test. There were no less than 12 systems 
testing eolleetively, simulating the Army Battle Command System 
(ABCS), headed by ATEC. However, there was neither 
eonfiguration eontrol nor a single point of eontaet. Eaeh system 
exeeuted separate test plans. Consequently, systems would drop off 
the grid in the middle of the test period, whieh adversely impaeted 
the already eomplex arehiteeture. Eor instanee, numerous times 
DDS would be down for maintenanee without notifieation. If 
proper shut down proeedures were not followed, null traeks would 
populate the arehiteeture. 

• Eow SA uptime pereentages refleeted the reliability of the 
eonneetion between the NOC, DDS, and GCCS-A in a eomplex 
network arehiteeture. Unit Task Organization eorruption was the 
leading C2 issue. 
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Event Date SW Version 

XCVR 

C2 SA 

RRE5 

Aug 09 

1.1.1 

BFTl 

35.0% 

0.0% 

FTl 

Oct 09 

1.1.4 

BFTl 

55.0% 

18.4% 

RRE6 

Mario 

1.1.4 

BFTl 

69.0% 

0.0% 

RRE 7 

Oct 10 

1.3 

BFTl 

54.4% 

27.0% 

FUE 1 

Dec 10 

1.3.1.1 

BFTl 

89.0% 

38.0% 

FT 2 

Feb 11 

1.3.1.1 

BFTl 

40.0% 

37.0% 

RRE 8 

April 

1.3.1.2 

BFT2 

88.0% 

12.0% 

FUE 2 

Jun 11 

1.3.1.2 

BFT2 

83.0% 

39.2% 

Arch. Test 

Oct 11 

1.3.1.2 

BFT2 

N/A 

83.2% 

RRE 9 

Oct 11 

1.3.1.3 

BFT2 

95.2% 

93.8% 

FUE 3 

Nov 11 

1.3.1.3 

BFT2 

75.8% 

88.3% 

RRE 10 

Mar 12 

1.3.1.4 

BFT2 

100% 

80.1% 

SI PR Event 

May 12 

1.3.1.4 

BFT2 

87.6% 

93.2% 



Figure 8. Calculated C2/SA (From Product Manager, DFSA, 2011 


The test team worked furiously with their Army counterpart to gain a better 
understanding of the issues and to address potential challenges. Additionally, a Data 
Exposure Working Group was established that included members from the FBCB2, 
Mission Command, and JBCP FoS PMOs. The group’s objectives were to work through 
the issues identified by the test team, identify problem areas, and develop and 
recommend solutions. As a result of the multipronged effort, the following resolutions 
were implemented. 

• New tactics, techniques, and procedures (TTPs) were developed to support 
the data flow. 

• Procedures were included in the field service bulletin that published the 
proper system maintenance sequence. 

• Vital processes were documented and proven. 

o The Marine Corps address book was uploaded to the C2R server, 
o The Marine Corps’ Unit Task Organization was downloaded from 
the C2R server. 

o Both JCR Terrestrial and JCR Celestial, with KGV-72, were 
configured and operated properly. 

• DC, CD&I redefined how JCR was to be evaluated. 
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The Increment II SA thresholds were used instead of the ones 
listed in the DACT ORD (originally 100% SA at all times, now 
only 75% PLI of the platforms in immediate battlespace and 50% 
in the extended, which changed how the percentages would be 
calculated). 

• The developer included main Marine Corps fixes in follow-on software 
releases that made the software more stable. 

Once all the changes were implemented, there were significant improvements in 
the C2/SA percentages (reference Figure 8, after FUE 2). More important, all future tests 
were under configuration management with better communication between test personnel 
for the different systems. It was understood that each event was a system-of-systems test 
and joint effort. 

Leadership from the PMO, Marine Corps Operational Test and Evaluation 
Activity (MCOTEA), and DC, CD&I met on a number of occasions with their Army 
counterparts to discuss the way ahead for JCR. The Marine Corps stakeholders 
determined a specific Marine Corps operational test (OT) was not necessary. The 
leadership considered a number of reasons before making the decision. 

• The Director, Operational Test and Evaluation (DOT&E) had approved 
the executed combined PM PBCB2 Updated JCR Test and Evaluation 
Strategy (2010), with capstone events (i.e., ET, EUE, and LUT) to support 
the Army fielding decision. These events included a combination of field 
test, limited user test, and field user evaluations. 

• Eield Test 2 (ET2) 

■ The purpose of ET2 was to conduct a structured, controlled, and 
formally evaluated field test within an operational architecture 
using soldiers and mission-based test conduct to obtain 
performance and reliability data on JCR version 1.3.1. 

■ The objectives were to evaluate 

• C2 and SA performance, 

• soldier management of the network, 

• initialization (platform and NOC) and the JCR database, 

• Type 1 encryption measures, and 

• Service interoperability between the different 
communication paths: 
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o Celestial to Terrestrial, 
o the ABCS and backward compatibility, and 
o Army and Marine Corps platforms. 

o Limited User Tests (in conjunction with FUE 2 and 3) 

■ The supporting units were 3rd Brigade, 1st Armored Division, 1- 
41 Infantry Battalion, and elements from l'^^ Marine Expeditionary 
Eorce equipped with JCR version 1.3.1. 

■ The evaluation objectives were the following: 

• support the EBCB2-JCR fielding decision; 

• assess 

o Entirely new software code, but with the same 
basic function as previously; 
o The new database structure and SA process 
(SDSA); 

o The improvements made to the E-Band Network 
Operations Center; 

o The Type 1 encryption device; and 
o Total system information assurance; 

• address outstanding issues from previous test events such 
as 

o Celestial to Terrestrial interoperability, 
o Network configuration and management, 
o Classified messaging, and 
o Reliability of the platform integrations; 

• evaluate training and maintainability; and 

• demonstrate interoperability with the joint community. 

• JCR underwent a robust DT strategy and its capabilities have proven more 
capable than envisioned. 

• The JBC-P EoS PMO exhausted its resources towards DT and completed 
multiple EUEs. 

• The JCR software matured and test results remained consistent with 
expectations. 

• MCOTEA observed all DT events and provided the PMO with an 
operational assessment of the JCR capabilities. 

• Initial JITC Message Conformance Test (MCT) was conducted in August 
2011 at the MCTSSA site. Many trouble reports were generated and 
provided to the developer. Eixes were included with follow-on software 
patches that resolved the most critical issues. The MCT was redone to 
verify resolutions of the priority areas. 


31 



The following section relies heavily on the JBC-P FoS JCR NIE 12.2 Test Report 
(SPAWAR, Atlantic, 2012a) provided by the JBC-P PMO. 

The test team evaluated the JCR capabilities on the operational Secret Internet 
Protocol Router Network (SIPRNET). The test plan was developed to verify and validate 
JCR functionality in the planned USMC and Army architecture on the live operational 
network (SPARWAR, Atlantic, 2012a, p. 4). The SIPR Event was conducted at the 
MCTSSA site in conjunction with NIE 12.2 (Army unit at Eort Bliss, TX). The Marine 
Corps’ JCR fielding software solution, version 1.3.1.4, was evaluated within the live 
architecture. The Texas A&M University (n.d.) security webpage describes the 
SIPRNET: 

The SIPRNET is the Department of Defense’s largest network for the 
exchange of classified information and messages at the SECRET level. It 
supports the Global Command and Control System, the Defense Message 
System, and numerous other classified warfighting and planning 
applications. Although the SIPRNET uses the same communications 
procedures as the Internet, it has dedicated and encrypted lines that are 
separate from all other communications systems. It is the classified 
counterpart of the Unclassified but Sensitive Internet Protocol Router 
Network (NIPRNET), which provides seamless interoperability for 
unclassified combat support applications and controlled access to the 
Internet. 

Test cases were generated to focus on functionality and interoperability between 
the Army and the Marine Corps. The test was executed for 80.75 hours. Both SA and C2 
uptimes exceeded the thresholds (SA 75.25 hours [93.2% of total time] and C2 70.75 
[87.6%]). During this evaluation, issues with C2 and SA were experienced by the team. 
However, swift coordination with subject-matter experts at the CTSE and NOC identified 
and resolved the issues. Two of the major issues were related to SA flow from the DDS 
and pulling the unit task organizations from C2R. The following excerpts are from the 
SPAWAR NIE 12.2 Test Report (SPAWAR, Atlantic, 2012a) that describes the two 
issues and resolutions. 

The team discovered that DDS peering issues contributed to a majority of 
SA loss between USMC terrestrial and celestial systems. DDS developers 
located at CTES and APG resolved the issues when they occurred. Other 
contributing factors to SA loss were due to lOS and GCCS-J CST 
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corruptions. The team was required to request additional ports from the 
Marine Corps Network Operations and Security Center (MCNOSC) on 
SIPR for CST connections between CTSF and MCTSSA. There were two 
eontributing faetors to the loss of C2. [The] first issue was with the NOC 
C2 gateway crashing. These instanees were observed on three oecasions 
during this evaluation. The NOC has submitted an SCR for a fix 
(SCR T25962). On May 22"“^, the NOC applied a hot fix that resolved this 
issue. Further instances of the NOC C2 Gateway eashes were not observed 
following the applieation of the hot fix. The seeond eontributing factor to 
loss of C2 for USMC systems was due to routing issues between 
MCTSSA and APG. Network engineers added the necessary route to both 
routers to enable C2 traffic to traverse the network. 

Issues were encountered when the team attempted to pull Army UTO 
datasets from C2R via the MRC UTO application. Working with C2R and 
JCR developers, the team found that certificates issued from the C2R FSR 
for MRC systems were not properly authenticating with C2R. The 
permissions set on the “key store” certificate and “trust store” certifieate 
were set to “root” when permissions needed to be set for the “C2Rservice” 
accessing the certificates. The issue highlighted a certificate distribution 
issue between USMC and Army that prompted diseussing between both 
project offices. (SPAWAR, Atlantic, 2012a, p. 7) 

Figure 9 is the cumulative list of all the SIPR Event’s test cases completed with 
their status. 
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Test Case 

Status 

1.1 Map Accuracy 

PASS 

1.2 Map Scale 

PASS 

2.1 VMF Messages 

PASS 

3.1 Overlay Transmit and Receive 

PASS 

4.1 PLI Completeness 

PASS 

4.2 Average Time for Updates 

PASS 

4.3 PLI Display 

PASS 

5.1 Verrify Interoperability 

PASS 

6.1 Purging GPS Key 

PASS 

6.2 Remotely Purging the Systems 

PASS 

7.1 Chat Capability 

PASS 

USA: 1.1 C2R Load of USMC Role Data 

PASS 

USA: 1.2 USMC Initialization 

PASS 

USA: 3.1 USMC Terrestrial to USMC Celestial (C2) 

PASS 

USA: 4.3.1 USMC Terrestrial to USMC/Army Celestial (SA) 

PASS 

USA: 4.3.2 USMC/Army Celestial to USMC Terrestrial (SA) 

PASS 

USA: 6.1 Adding Army Role Data to USMC Address Book Through Hook 

PASS 

USA: 6.2 USMC C2R Pull of Army SDSA 

PASS 

USA: 17.1 NOC DDS to CORE DDS Network Loss 

PASS 

USA: 17.2 Restart of GCCS-A COP Zone 

PASS 

USA: 17.3 Clearing of GCCS-A PLI 

PASS 

USA: 17 4 DDS Clears GCCS-A Topics 

PASS 

USA: 17.5 Restart of USMC BNJTCW 

PASS 

USA: 17.6 Restart of USMC HHQ lOS 

PASS 

USA: 17.7 USMC REGT lOS to HHQ lOS Network Loss 

PASS 

USA: 17.8 Restart of USMC REGT lOS 

PASS 

USA: 17.9 Clearing of HHQ lOS PLI 

PASS 

USA: 17.10 USMC REG JTCW Network Loss 

PASS 

USA: 17.11 Restart of USMC REG JTCW 

PASS 

USA: 17 12 USMC BNJTCW Network Loss 

PASS 

USA: 17.13 Restart of USMC BN JTCW 

PASS 

USA: 17.14 Clearing of REG JTCW PLI 

PASS 

USA: 17.15 Attempt to Create the USMC "Null" Track 

PASS 


Figure 9. Cumulative Test Cases (From SPAWAR, Atlantic, 2012a) 


The SIPR Event was the last Marine Corps-declared JCR test event to evaluate its 
operational effectiveness. For all future DT events, JCR will be evaluated on a limited 
basis, primarily to assess compatibility with the Increment II capabilities. 
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B. INCREMENT II—JOINT BATTLE COMMAND-PLATFORM 

I. Overview 

Joint Battle Command-Platform (JBC-P) is the next generation FBCB2 system. 
The JBC-P is an Army-led Acquisition Category (ACAT) II program designated by the 
Joint Requirement Oversight Council (JROC) as having joint interest. The system 
supports the Tier 1 Joint Capability Areas of Joint C2, Joint Battlespace Awareness, and 
Joint Net-Centric Operations (Marine Corps Systems Command, 2012, p. 9). JBC-P 
achieves digital information (C2 and SA) interoperability, vertically and horizontally 
between joint warfighting elements in current and future operating environments. JBC-P 
will leverage BFT FoS hardware and add capabilities to include handheld devices and 
beacon systems. JBC-P capabilities increase accuracy and density of SA to further 
mitigate risk of fratricide. Additionally, the system increases the efficiency of orders 
transmission; graphical overlays; and friendly, hostile, neutral, unknown, and non- 
combatant SA (SPAWAR, Atlantic, 2011, p. 3). The system improvements/enhancements 
will answer JROC convergence directives. 

The PEO C3T is the Milestone Decision Authority (MDA) for the JBC-P 
program. The MDA officially initiated JBC-P software development, and the program 
entered the acquisition cycle at MS B in September, 2009 (Department of the Army, PEO 
C3T, 2009). The program received MS C approval on July, 17, 2012 (Department of the 
Army, PEO C3T, 2012). Commander, MARCORSYSCOM is the Program Decision 
Authority (PDA) for the Marine Corps, as a participating service. PDA ADM (Marine 
Corps System Command, 2011) “authorizes the Marine Corps continued participation in 
the Army’s program.” MARCORSYSCOM manages the program as the JBC-P Eamily 
of Systems (EoS). The PMO is comprised of Increment I (BET EoS) engineers, 
logisticians (government and support contractor), and JBC-P specific engineering team. 
The JBC-P FoS Life Cyle Cost Estimate (Marine Corps Systems Command, 2012) 
describes the JBC-P EoS as the following: 

[A] Weapon System program with a product line made up of systems and 
products formerly associated with the Blue Eorce Tracker (BET) EoS 
(Increment I) and JBC-P (Increment II). The United States Marine Corps 
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(USMC) is participating in the U.S. Army (USA) JBC-P program under 
the authority of the Commander, Marine Corps Systems Command 
(MCSC) and will not be entering into an acquisition milestone decision 
process. The term JBC-P FoS encompasses both Increment I and 
Increment II. Increment I consists of ICR software, BFT mounted 
systems. Tactical Operations Center (TOC) Kits, the improved BFT-2 
transceiver, and the KGV-72 National Security Agency (NSA) Type 1 
Programmable In-Line Encryption Device (PIED), (p. 9) 

According to Director, Capabilities Development Directorate Eetter of 
Clarification (EOC; 2012), the “established JBC-P EoS Authorized Acquisition Objective 
(AAO) is 26,566 systems (Handheld: 6,920, Mounted: 18,275, TOC Kit: 1,371)” (p. 1). 
The PMO fielding strategy for the JBC-P capabilities is aligned with the Army’s. If the 
schedule holds, both Services will request a fielding decision in 1st quarter PY2014 after 
a successful operational test. According to the JBC-P CDD (Department of the Army, 
2008), “initial operational capability (IOC) is achieved when one Marine Corps Regiment 
is completely fielded with all variations of the JBC-P Product Eine” (p. 65). The IOC is 
tentatively scheduled for 4th quarter EY2014. Eigure 10 depicts the JBC-P EoS schedule. 

Moreover, JBC-P EoS is currently supported by separate funding lines for the 
individual increments. Eate in EY2012, the PMO initiated a two-year transition strategy 
to merge acquisition efforts along with funding lines in order to support planned PY2014 
Increment II fielding. 
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Figure 10. JBC-P FoS Major Events Schedule (From Product Manager, DFSA, 2012) 


JCR version 1.3 is the baseline for the JBC-P software to reduce the development 
risk associated with software development. JBC-P enhances both FBCB2 and DACT 
capabilities and leverages mature technologies that have been combat proven by both the 
Marine Corps and Army. PM FBCB2 established an MOA with the government software 
development agency, Aviation and Missile Research, Development and Engineering 
Center (AMRDEC) Software Engineering Directorate (SED), in Huntsville, AE, to 
develop and integrate the JBC-P capabilities (Program Manager Eorce XXI Battle 
Command Brigade and Below, PEO C3T, 2009, p. 20). The enhanced capabilities will 
leverage the current JCR NOC and existing network architecture. The JBC-P TEMP 
provides more clarity on the upgrade. 

JBC-P builds on the experience of over thirteen years of evolutionary 
development of digital, battle command information systems that provides 
integrated, on-the-move, timely, relevant Command and Control/ 
situational awareness (C2/SA) information to tactical combat, combat 
support and combat service support commanders, leaders, and key C2 
nodes. The first increment (PBCB2) concentrated on the capabilities 
required to prosecute the close fight and was primarily focused on the 
Army units at the Brigade and Below. The second increment, the JBC-P 
program, will become the cornerstone of the Joint Blue Eorce Situational 
Awareness (JBESA) envisioned to support the joint warfighter. The JBC-P 
program will be an evolutionary acquisition delivering JBC-P software, 
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leveraging on existing assets and new hardware capabilities. Future JBC-P 
hardware procurements will be directly linked to the JBC-P software 
development efforts as a baseline requirement. Subsequent future 
contracts for JBC-P hardware will be obtained with full and open 
competition with a requirement to perform with the JBC-P software, (p. 

20 ) 

2. Capabilities 

This section was extracted from the JROC validated and approved JBC-P CDD, 
dated May 6, 2008 (Department of the Army, 2008). The document is a conversion from 
the Army FBCB2 ORD and Marine Corps DACT ORD, to a JBC-P CDD (Department of 
the Army, 2008, p. 20). The JBC-P CDD also states the basis for JBC-P as “the Joint 
Requirements Oversight Council Memorandums 161-03 and 163-04 directive to 
converge to a single JBFSA capability for the Army and Marine Corps” (Department of 
the Army, 2008, p. 2). Additionally, the document takes into consideration and leverages 
a number of fielded systems and others still in development. 

The JBC-P capabilities include the following: 

• provides an enhanced situational awareness of the environment as well as 
enhanced collaborative decision-making processes, 

• allows joint forces to exploit network linkages among dispersed joint 
forces to improve coordinated maneuver and integrated situational 
awareness, 

• allows the future joint forces to be able to share and exchange information, 

• supports a system that is deployable worldwide, and 

• supports all types of units and operations. Additionally, the system allows 
for the joint force to rapidly shift from one operation to another with little 
to no interruption. (Department of the Army, 2008, p. 9) 

Moreover, the CDD describes the JBC-P strategy as the following: 

The overall JBC-P strategy is to provide incremental capabilities to the 
joint force that support current and future joint operational concepts. 

Based on funding, technical feasibility, performance and/or schedule 
issues, particular JBC-P increments may only provide partial capability. 

We will develop future increments as the joint warfighters increase 
their understanding of already developed capabilities and required 
Transformational technologies continue to mature. (Department of the 
Army, 2008, p. 14) 
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d. Key Performance Parameters 

The following JBC-P CDD (Department of the Army, 2008) excerpts 
provide details on the system’s key performance parameters (KPP) along with each 
corresponding threshold and objective measure. 

KPP 1. Net Ready. 

JBC-P must support Net-Centric military operations. JBC-P must be able 
to enter and be managed in the network, and exchange data in a secure 
manner to enhance mission effectiveness. JBC-P must continuously 
provide survivable, interoperable, secure, and operationally effective 
information exchanges to enable a Net-Centric military capability. 

(a) Threshold. JBC-P must fully support execution of joint critical 
operational activities identified in the applicable joint and system 
integrated architectures and the system must satisfy the technical 
requirements for transition to Net-Centric military operations. 

(b) Objective. JBC-P must fully support execution of all operational 
activities identified in the applicable joint and system integrated 
architectures and the system must satisfy the technical requirements for 
Net-Centric military operations. (Department of the Army, 2008, p. 15) 

KPP 2. Shared Blue Situational Awareness. 

(a) Threshold. All Operational JBC-P equipped platforms must display, as 
reported by other JBC-P FoS, 75% of joint PLI within the platform 
immediate battlespace and 65% within the platform extended battlespace. 

The friendly location data will be accurate to within 200 meters for ground 
platforms, 50 meters for dismounted soldiers, 500 meters for rotary wing 
or UAV aircraft of the actual position. For relatively stationary platforms 
the PLI data will be reported within 20 minutes for ground mounted and 
dismounted platforms and 2 minutes for aviation platforms. 

(b) Objective. All Operational JBC-P shall display, as reported by other 
JBC-P FoS, 95% of joint PLI w/in immediate battlespace and 85% w/in 
extended battlespace. The friendly location data will be accurate to within 
100 meters platform, 10 meters dismounted soldier, 250 meters rotary 
wing/UAV aircraft of the actual position. (Department of the Army, 2008, 
p. 16) 

KPP 3. Shared Survivability 


(a) Threshold. Survivability information, as reported by JBC-P FoS, must 
be displayed and an alert provided on 75% of operational JBC-P equipped 
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platforms within the applicable danger zone within the specified time of 
the entity being reported. 

(b) Objective. Survivability information, as reported by JBC-P FoS, must 
be displayed and an alert provided on 95% of operational JBC-P equipped 
platforms within the applicable danger zone within the specified time of 
the entity being reported. (Department of the Army, 2008, p. 16) 

KPP 4. Sustainment (Materiel Availability). 

(a) Threshold. The operational availability for the JBC-P shall be 90%. 

(b) Objective. 95%. (Department of the Army, 2008, p. 16) 

e. Handheld 

The handheld solution is no longer under the JBC-P development effort. 
The requirement has transitioned to the Nett Warrior dismounted effort. The Nett Warrior 
CDD requirements were mapped against the JBC-P CDD and a determination was made 
that they were similar enough that Nett Warrior would take responsibility. However, the 
Marine Corps still relies on the JBC-P CDD for its solution, particularly for testing. The 
JBC-P FoS PMO established a workgroup to determine what specific Marine Corps 
interoperability requirements are met in the Nett Warrior CDD. The workgroup results 
are still pending. Furthermore, the PMO is uncertain the solution will be ready for the 
planned lOT&E during NIE 13.2. 

3. Software Builds 

Part of the Army’s modernization strategy is to develop, test, and field associated 
capabilities collectively to the warfighter. Capability sets are inceptions of this strategy. 
The JROC-approved JBC-P CDD operational requirements were prioritized to be 
developed accordingly via software builds. The software builds are incorporated within 
pooled capability sets (CS) and evaluated for fielding during the NIE. Subsequent 
software builds on the previous software. JBCP is being developed incrementally, and 
this approach supports the program strategy. A combined team that included 
representatives from the Marine Corps, Army, Special Operations Eorces, and other 
stakeholders completed the prioritized list of requirements. The team conducted a System 
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Requirements Review (SRR) semi-annually to review the prioritized list. During the 
SRR, the team recommended changes to existing requirements or introduces new ones. 

There are specific artifacts that are associated with introducing capabilities into 
JBCP software builds in which the Marine Corps have been participating in. The platform 
software is the same for the Marine Corps and Army. However, the Marine Corps team 
has been developing its own capabilities packages for the builds. These capabilities are 
specific to Marine Corps higher echelon requirements. Currently, JBC-P has four 
software builds that comprise the core system requirements. These initial software builds 
contain the bulk of the Army requirements and the Marine Corps’ interoperability 
requirements. Software Build Four contains the capability to interface with JTCW. It 
includes the ability to share VMF with JTCW and to send PLI reports to JTCW. Software 
Build Four is a deliverable for CS 13. The following provides the Army clarification for 
CS 13. 

CS 13 will begin to field to eight brigade combat teams in 2012. CS 13 is 
the first fully-integrated suite of network components fielded as part of 
Capability Set Management and as a result of the Army’s new Agile 
Process. CS 13 delivers an unprecedented integrated network solution 
capable of supporting mission command requirements for the full range of 
Army operations, and an integrated voice and data capability throughout 
the entire BCT formation. (Department of the Army, n.d.a) 

Software Build Five is projected to include additional Marine Corps capabilities 
required for JBC-P initial fielding. The build includes the ability to build overlays, pull 
unit and platform tracks along with PLI from JTCW, and push out to selected JBC-P 
users. Moreover, Build Five contains enhanced JTCW interoperability and initial 
interoperability capability with other Marine Corps-unique systems and tactical radio 
wave forms. 

4. Test and Evaluation 
a. Overview 

The Marine Corps test strategy is aligned to the Army. Both Services 


evaluate JBC-P capabilities utilizing the JBC-P CDD KPPs. Joint test events are 

conducted to maximize resources and better assess mutual requirements. When 
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necessary, the Marine Corps team conducts independent testing for specific Marine Corps 
requirements. In addition to the established test sites at SPAWAR and MCTSSA, the 
JBC-P FoS PMO provided test personnel to augment the Army’s test team collocated at 
the SED. This initial team’s primary mission is to conduct SSAT, in order to test Marine 
Corps-specific requirements in each build released by the developer. These three sites are 
mutually supported with dedicated personnel to assess each JBC-P software build. The 
comprehensive teams at the SPAWAR and MCTSSA are tasked with conducting all 
Increment I and Increment II development testing efforts. 

b. Test and Evaluation Master Plan 

The JBC-P Test and Evaluation Master Plan (TEMP) (U.S., Army Office 
of Program, FBCB2, 2011) underwent a vigorous review and edit process by the 
stakeholders. The finalized version is enroute to approval. The following provides more 
details on the document. 

The TEMP describes an integrated test and evaluation strategy that will 
leverage all available data sources including but not limited to plan 
developmental and operational testing. The TEMP also includes measures 
to evaluate the performance of the system during these test periods; an 
integrated test schedule; and the resource requirements to accomplish the 
planned testing. (U.S. Army Office of Program Office, FBCB2, 2011, 

p. 1-1) 

The following describes the JBC-P Test and Evaluation Working Integrated 
Product Team (T&E WIPT) that was established to be the focal point to manage testing. 

T&E WIPT membership will include all organizations having direct or 
indirect testing responsibilities. These organizations include: PM FBCB2, 
MARCORSYSCOM, Army Test and Evaluation Command (ATEC), PM 
Heavy Brigade Combat Team (HBCT), MCTSSA, SED, Central 
Technical Support Facility (CTSF) and the Joint Interoperability Test 
Center (JITC). The JBC-P system T&E concept includes test events 
conducted by both the contractor and the Government to ensure that the 
JBC-P software and hardware variants meet performance requirements, 
are safe for use by soldiers, are operationally suitable, survivable and 
effective, interoperable, and qualified for use. (U.S. Army Office of 
Program Office, FBCB2, 2011. p. 3-1) 
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c. Development Tests 

As a result of lessons learned from JCR testing, all JBC-P DT events are 
jointly coordinated. The PEO C3T ADM (Department of the Army, PEO C3T, 2012) 
requires the PMO to “conduct a formal DT and EUT to confirm the system’s readiness to 
conduct Initial Operational Test and Evaluation (lOT&E)” (p. 1). Moreover, the ADM 
states that the PMO must “return to the MDA post EUT and provide an update. MDA 
must be confident of system maturity and ability to meet criteria to enter lOT&E, else 
approval will be rescinded” (Department of the Army, PEO C3T, 2012, p. 1). Each 
software build released by the developers undergoes the same series of test events as 
JCR, SSAT, RRE, JITC Certification, Risk Assessment, and EUE/EUT/NIE. The 
SPAWAR Software Test Report (SPAWAR, Atlantic, 2012b) states the major difference 
between the RREs for JCR and JBC-P is that the JBC-P “event architecture not only 
provides the connectivity to exercise VME messaging, PEI, and interoperability, but also 
backwards compatibility with JCR” (p. 2). Additionally, joint User Juries were conducted 
during the early stages of development to solicit feedback from fleet Marines and 
soldiers. The users evaluated handheld prototypes and the mounted software and then 
completed surveys at the conclusion of each event. The feedback drove the development 
effort for the new user interface that is similar to today’s gaming interface. 
Representatives from the TICM, CD&I, SED, JBC-P EoS PMO, and PM PBCB2 
executed and monitored each event. 

(1) Results. The Marine Corps Test Team was not actively 
engaged in testing of the first three software builds. The builds did not address Marine 
Corps requirements, so the team’s role was limited. Software Build Pour was the first to 
complete the full gamut of test events by both Services. RRE-11 was completed 
September 10, 2012. Overall, the test was a success. The test team identified numerous 
issues with the software build. The SPAWAR Software Test Report for the JBC-P RRE- 
11 Test Event (SPAWAR, Atlantic, 2012b) states that the priority issues were “incorrect 
Marine Corps symbol code information displayed on the JTCW, [the] data set (UTO) 
used by JBC-P was unique and not compatible with JCR (different formats), and field 
orders sent from JBC-P were unable to send attached overlays that contained free draw 
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objects” (p. 5). The priority issues were resolved after coordinating with the Army team. 
The fixes were promptly “integrated and distributed to all test sites to improve software 
stability” (SPAWAR, Atlantic, 2012b, p. 6). At the event conclusion, the test team 
recommended to “refine and publish USMC data initialization processes for inclusion of 
USMC JBC-P roles in the test build [and] ... USMC data initialization processes for JCR 
test UTO distribution and loading of data into C2R” (SPAWAR, Atlantic, 2012b, p. 7). 

In November 2012, the Marine Corps conducted an FUE in 
conjunction with NIE 13.1. The EUE was successful in evaluating JTCW interoperability 
utilizing static MCTSSA JBC-P platforms. The EUE test report is being incorporated 
with the Army’s NIE 13.1 report and is not yet finalized. 

d. Operational Testing 

PEO C3T ADM (Department of the Army, PEO C3T, 2012) “authorized 
entry into the Eow Rate Initial Production (ERIP) phase for the purpose of completing 
manufacturing development and conducting lOT&E.” NIE 13.2, scheduled to begin 
March 2013, will be the lOT&E event. Eor both Services, Software Build Eive will 
support the scheduled lOT&E. The JBC-P EoS PMO is awaiting delivery of the software 
build to schedule the required SSAT and RRE. The JBC-P TEMP (U.S. Army Office of 
the Program Office, 2011) states that the lOT&E objectives are to “ensure the ability of 
the JBC-P to be integrated on a variety of system platforms without inhibiting soldier 
performance, seamlessly interoperate with Battle Command Systems, and evaluate JBC- 
P’s operational effectiveness, suitability, and survivability” (p. 3-4). The draft TEMP 
also describes each Service DOT&E activity’s responsibility for operational testing. It 
designates ATEC as the lead OT agency (lead evaluator) and MCOTEA as supporting 
agency. The following TEMP excerpt provides details on each activity’s responsibility: 

ATEC is responsible for planning and conducting developmental and 
operational testing and completing independent system evaluations of the 
JBC-P systems. Both the Developmental Test Command (DTC) and 
Operational Test Command (OTC) develop test plans and instrumentation 
to support testing, as well as conduct test events... 
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Marine Corps Operational Test and Evaluation Activity (MCOTEA) 
independently plans, executes and evaluates testing of material solutions 
against Warfighter capabilities, under prescribed realistic conditions and 
doctrine, to determine operational effectiveness and suitability. MCOTEA 
is the authority for Operational Test and Evaluation for the USMC and 
will plan and execute USMC-specific OT&E. MCOTEA will support 
ATEC for Joint Interoperability T&E planning and reporting. (U.S. Army 
Office of Program Office, EBCB2, 2011, p. 2-2) 

To effectively simulate the realistic operational environment, the agencies are 
coordinating to attach the Marine Corps unit to the OTC unit at Eort Bliss. A truly joint 
evaluation that includes an assortment of Marines and Soldiers from one location has 
always been a goal on this effort and also DOT&E encouraged. 

C. SUMMARY 

This chapter provided the reader with details on the incremental approach effort to 
reach SA convergence. It also described each increment’s capabilities, test and evaluation 
efforts and results of each test effort. 
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IV. CONSIDERATIONS 


This chapter will provide some key considerations from the analysis of Increment 
I and Increment 11. It will describe some Army unique resourees that impact how the 
Marine Corps will implement the increments. 

Joint Capabilities Release (JCR) and Joint Battle Command-Platform (JBC-P) 
were intended to address the Joint Requirements Oversight Council (JROC) directive for 
a joint blue force tracking capability for the ground forces. However, both software 
solutions are more Army centric than Marine Corps centric. As a result, mismatehes exist 
within and beyond the JBC-P between the Army and the Marine Corps. The primary 
challenge for the Marine Corps’ team is marrying JBC-P with organic Marine Air- 
Ground Task Force (MAGTF) systems. Additionally, the Marine Corps shares the current 
theater of operations with the Army. The L-band satellite infrastructure is fully supported 
with Army resources. The Marine Corps will be challenged when operating 
independently. Moreover, the JBC-P development schedule has shifted and many of the 
Marine Corps eapabilities are prioritized lower than the Army’s. Consequently, the 
Marine Corps schedule may be disjointed from the Army’s fielding strategy. 

A. SYSTEM DEPENDENCIES 

JROC Memorandum 163-04 (JROC, 2004) required the Army and the Marine 
Corps to adopt the same C2SA systems for their entire hierarchy. The memorandum 
directed the Army to adapt the Joint Tactieal Common Operating Picture (COP) 
Workstation (JTCW) for the brigade and above solution and the Marine Corps to adapt 
FBCB2 for its platforms (battalion and below; JROC, 2004). However, the Army moved 
away from that path and designed JCR and JBC-P for the higher echelon solution, using 
the Army Battle Command System (ABCS) instead of JTCW. The Marine Corps requires 
JTCW to synchronize all the systems within the MAGTF architecture. JCR and JBC-P 
are essentially designed towards external resources that reside within the ABCS and 
operate as a system of systems. Those external resources are dependent on the system 
that the Marine Corps must accommodate. Marine Corps CONOPS was tailored to 
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function within the current technical parameters versus supporting tactical networks in 
order to make JCR and JBC-P operationally effective for Marine Corps units. The 
dependencies further complicate the already tangled architecture and increase the chance 
for potential network disruption. This issue exists in Increment I and has not been 
completely resolved for Increment II. 

B. COMMAND AND CONTROL REGISTRY 

The Marine Corps does not have a high tier address book concept for all its units 
that is similar to the Command and Control Registry (C2R). Data products such as unit 
reference numbers (URN), organization structure, and Internet protocol (IP) addresses 
must be loaded to C2R in order to operate on the network. The Army established Project 
Director Tactical Network Initialization (PDTNI) to manage all data products for ABCS. 
The PDTNI collects and manages all data products to enable digital communication and 
interoperability across its tactical Internet (peoc3t.army.mil/tni). In the Marine Corps, 
individual units are responsible to configure their IP addresses. They assign their unit 
names to be used and create the IP structure for the organization. The Marine Corps’ 
expeditionary nature and consequent constant changing of IPs and network structure do 
not support the C2R concept. 

C. UNIVERSAL COLLABORATION BRIDGE 

There is a distributed chat capability that is associated with JBC-P. Within the 
ABCS, the Universal Collaboration Bridge (UCB) program provides a translation service 
to JBC-P. UCB translates one chat protocol to another for the ABCS system-of-systems 
concept. The Marine Corps has no equivalent service. The Marine Corps team is working 
on a solution in order to transmit JTCW-generated messages to JBC-P. 

D. DATA DISTRIBUTION SYSTEM 

Service interoperability is dependent on the Data Distribution System (DDS), 
Global Command and Control System-Army (GCCS-A), and the Army Service 
Component Command (Army cell) collocated with the regional COCOM. The 
procedures to enable data flow to the joint community, via both JCR and JBC-P, have not 
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been solidified as yet. The connection has been sporadic during DT for a number of 
different reasons. The Marine Corps team does not have a high degree of confidence the 
transmissions to the joint community will be seamless in operational environments. 
Situational awareness reliability during prior test events provided an indicator of a 
complicated configuration that is difficult to maintain. Additionally, a major challenge 
yet to be executed is establishing a connection from a Marine Expeditionary Unit, 
embarked on a naval vessel, to a regional COCOM. 

E. SATELLITE COVERAGE 

BET satellite coverage is not global, and with the current fiscal environment, 
global coverage once JCR and JBC-P are fielded may not be achievable. The Marine 
Corps has been sharing the battlespace with Army units executing combat operations in 
support of the Global War on Terrorism. Thus far, the Army has been financing the 
limited Marine Corps’ E-band bandwidth usage. However, today’s BET satellite coverage 
area does not support expeditionary operations. Once JCR and JBC-P is widely fielded 
throughout the Marine Corps operating force and, specifically, the Marine Expeditionary 
Units, the Marine Corps will have to support its satellite usage. Currently, the Army 
provides BET coverage only for regions where BET-equipped Army units are located. 
The Defense Information Systems Agency (DISA), in the near future, will be responsible 
for managing all E-band satellite contracts for the DoD. The JBC-P EoS PMO is 
anticipating a request for funding from DISA in the near future to support a wider 
satellite coverage area. Revealed during discussions with PMO leadership, this issue is a 
top primary and has been briefed to Headquarters Marine Corps Command, Control, 
Communications, Computers, and Intelligence for resolution. 

F. SCHEDULE SHIFT 

The incremental improvement approach for JBC-P software development has 
been a challenge for the developer. Each proceeding software build contains more 
capabilities than the previous version. The initial coupled capabilities priority list has 
changed and some Marine Corps-specific requirements were lowered. Eurthermore, no 
developmental plan currently exists for some of the lowered priority requirements, and 
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the developer has struggled to achieve the threshold capabilities in Build Four. Early test 
results show limitations exist with the variable message format (VMF) standard, which is 
a significant requirement for JTCW. The originally planned capabilities in Build Five are 
the first Marine Corps fieldable version of the JBC-P software. The PMO is not confident 
follow-on Software Build Five will contain improved VMF capabilities. Additionally, the 
Marine Corps expected an improved JTCW interface in Build Five to go beyond the 
threshold interoperability capabilities. The expected capabilities include: Improved tracks 
and overlays exchanges, automated updates to the operational picture in JTCW, and 
JTCW data exchanges with JBC-P. Additionally, the PMO anticipated improvements in 
the functional address book process that facilitates address book information interactions 
between the Army and the Marine Corps systems. 

Moreover, the current constrained budgetary environment negatively impacted 
JBC-P funding. The development effort changed to accommodate the reduced resources. 
The PMO is not confident the final build will remain on schedule and anticipates 
significant shifts in the Software Build Five release schedule. The constraints have 
reduced the Marine Corps’ upcoming future years’ budgetary controls. Supporting 
Increment I-equipped units in OEF is priority. Therefore, procuring the hardware 
upgrades associated with Increment II in a timely manner will be a challenge. 

G. SUMMARY 

This chapter provided key considerations that hamper Marine Corps 
implementation of the ICR and JBC-P packages. 
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V. CONCLUSION 


This chapter summarizes what was learned while conducting this research. The 
ehapter provides reeommendations for proeedure and policy that will lessen the 
complexities of joint programs. Additionally, this chapter provides reeommendations for 
further researeh to better determine Increment II feasibility for fielding to the Marine 
Corps and analysis of Blue Force Tracker use in Marine Corps expeditionary operations 
other than war. 

A. SYNOPSIS 

The combination of the lethality of modern-day weaponry, the chaos that exists 
on a joint battlefield, human factors, and stove-piped tactical situational 
awareness/command and control systems has increased the potential for inadequate 
situational awareness and, in the worst case, fratricide occurrences. The Joint Oversight 
Requirement Committee’s direetive (JROCM, 2004) for a Joint Blue Foree Situational 
Awareness eapability is warranted to improve tactieal situational awareness and reduce 
fratrieide oeeurrenees. This analysis of the Marine Corps’ efforts toward a viable solution 
evideneed that the overarching capability, as envisioned by the JROC, cannot come to 
fruition in the near future. As is common in most joint efforts, differences exist between 
the Marine Corps and Army, primarily in regard to requirements and organic resources. 
These differences inhibit developmental efforts and hinder the likelihood of fielding 
similar and interoperable capabilities. 

The Marine Corps executed key efforts to eomply with the JROC eonvergence 
directive: First, the vehicle-mounted Data Automated Communications Terminal 
(DACT) variant was distributed to operating forees on a limited basis; second, fielding 
the dismounted DACT was cancelled; and third. Marine Corps System Command 
(MARCORSYSCOM) rapidly proeured the Army’s Blue Foree Tracker (BFT) systems 
and subsequently fielded to Marine units in the combat zones and at home stations. The 
MARCORSYSCOM program management office (PMO), Joint Battle Command- 
Platform Family of Systems (JBC-P FoS) initiated actions to align Marine Corps efforts 
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with the Army’s aggressive incremental strategy to develop the joint capability. PMO 
JBC-P FoS established dual Marine Corps-specific test sites, augmented the Army’s test 
team that was collocated with the software developers, and executed concurrent test 
events to synchronize with the Army test schedule. 

The convergence effort is plagued with challenges. Joint Capability Release 
(JCR) represents Increment I towards interoperability, but its software and hardware 
capabilities have not proven fully capable of meeting Marine Corps operational 
requirements. JCR is essentially designed towards the Army Battle Command System 
(ABCS). The enhanced capability requires an overly complex architecture that is 
dependent on organic ABCS resources that do not reside within the Marine Air-Ground 
Task Force architecture. This dependency was evident while testing JCR. Testing 
revealed an overarching lack of a reliable network for SA/C2 without altering Marine 
Corps concept of operations. Additionally, reasonable concerns exist in developing, 
testing, and concept of employment for Increment II, Joint Battle Command-Platform 
(JBC-P). JBC-P is being developed incrementally. The Services’ requirements were 
prioritized, coupled, and assigned to software builds. Each subsequent software build 
adds more capabilities to the previous. The software build development schedule shifted 
due to issues with the developer, which resulted in many Marine Corps-specific 
requirements being lowered on the priority list. Consequently, the planned Marine Corps 
fieldable solution is now delayed. 

Moreover, the Army maintains the L-Band satellite network, the architecture and 
resources required to operate the BFT system. JCR and JBC-P encompass enhanced 
capability to the current network and architecture. The Army provides satellite coverage 
for all regions where BFT-equipped Army units are located. However, the resources are 
limited outside those regions and may be unavailable for Marine forces conducting 
traditional expeditionary missions. 

B. LESSONS LEARNED 

1. JCR represents the interim solution towards full convergence. If the 
Marine Corps had greater influence during the JCR developmental phase, most of the 
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challenges would have been mitigated. JCR and subsequently, JBC-P, would have been 
designed to ultimately support the current Marine Corps architecture and concept of 
operations in the same manner as the Army. Additionally, greater influence during the 
negotiation sessions, where capability priorities were being established, would have 
ensured a practical Marine Corps solution and facilitated a seamless transition to JBC-P. 
The Marine Corps-specific requirements would have been equivalently considered when 
establishing the capabilities priority list. 

2. The Marine Corps resources are limited, but available resources should 
have been directed more efficiently. More resources should have been dedicated to 
expedite responses to the Army workgroup’s inquiries on Marine Corps capabilities. As 
the JCR effort winds down, more JBC-P FoS PMO assets are being dedicated to JBC-P. 
The purpose is to develop solutions to the existing architecture and capability issues that 
will make JBC-P a viable solution for Marine forces with reduced consideration for 
interoperability with the Army. 

3. The JBC-P FoS PMO should have more effectively communicated the 
JCR and JBC-P system requirements with other programs within the MAGTF 
architecture. There are several Marine Corps programs that have only recently been 
involved in evaluating the impact of fielding JCR and JBC-P. 

C. RECOMMENDATIONS 

1. Procedural 

For solutions intended for multi-Service purposes, the baseline design must 
support all Services’ resources. Consistency in the core design will facilitate 
implementation and ultimately enhance suitability. Program funding must be stabilized 
for incorporating all of the joint system requirements, not just the funded Service’s 
requirements. This is even more relevant during the foreseeable stringent budgetary 
environment, which dictates a heightened emphasis on commonality throughout the 
Services. Implementing JROC-mandated directives between the Services will be less 
challenging if solutions are designed towards an impartial Joint Capabilities Integration 
Development System process. 


53 



Moreover, additional consideration must be given to the fundamental nature in 
which each Service fights, while simultaneously maintaining the goal of Service 
interoperability. To be a tangible force multiplier, the capability must be designed to fit 
within the Service’s battlefield concept of employment and facilitate interoperability. 
Any deviation would diminish the capability’s value to the warfighter between the 
Services. Accomplishing this is extremely challenging as each Service must maintain the 
capability to operate with its existing, disparate C2/SA systems, while developing future 
systems that are interoperable. 

2. Policy 

Long-standing acquisition and funding policies, rooted in law, remain hindrances 
in developing truly joint systems. Acquisition funding primarily flows through each 
Service, which then prioritizes funding toward its own requirements, often at the expense 
of a less well-funded sister Service. While Congress is able to “fence” funding for 
programs through specific language in the annual appropriations bill, it would be difficult 
to address the specific requirements within the fenced program. This would continue to 
allow the funded Service to prioritize the Service-specific requirements and ignore the 
joint or sister Service requirements. This would result in the continued development of 
Service-specific C2/SA systems that are not particularly interoperable in the joint 
environment. In turn, future C2/SA developments would be constrained by the Service- 
specific system that was fielded and the issue would propagate infinitely. 

While the Joint Chiefs of Staff have influence on the acquisition process through 
the JROC, there is little that can be done when funding to develop a Service’s specific 
requirement is not available. Joint PMO’s that report directly to the Defense Acquisition 
Executive (DAE) have been established to help eliminate the problem with Service 
acquisition funding, and that may be one tactic that could be employed to keep the focus 
on the joint requirements. 
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3. 


For Further Research 


Marine Corps’ JBC-P Fielding Strategy After Network Integration 
Evaluation 13.2 and Other Follow-On Evaluations 

This analysis is insufficient to determine the feasibility of the Joint Battle 
Command-Platform (JBC-P) capabilities within the Marine Corps and realizing the Joint 
Requirements Oversight Council vision for full Blue Force Situational Awareness 
convergence. Better determination of the operational effectiveness and suitability of JBC- 
P, within the Marine Air-Ground Task Force architecture, will be made by analyzing the 
initial operational test and evaluation test report from Network Integration Evaluation 
13.2 (March to May 2013). 

Analyze BFT Use During Marine Corps Expeditionary Operations Other 
Than War 

Findings from this analysis may provide a realistic view of the complexity of joint 
systems while meeting Service-specific requirements. Additionally, the findings may 
help determine specific Marine Corps capabilities that should be included in future JBC-P 
versions to support traditional expeditionary operations other than war (e.g., humanitarian 
assistance, disaster relief, and noncombatant evacuations). However, the Marine Corps 
should evaluate BFT usage in areas independent of Army resources to better determine 
suitability and reliability of the satellite network. 
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APPENDIX 


Sample Risk Reduction Event Test Cases 
Attribute: Maps 

Capability Statements: A Key Performance Parameter (KPP) for the DACT 
consists of the ability to display a map with GPS-derived position location 
information (PLI) [Interoperability KPP] represented on the map. 

Measure: % Scalability. 

Measure: % Successful Map Retrieval. 

Measure: % Accurate Display. 

Measure: Storage Capacity. 

Attribute: Geodetic Reference and Navigation 

Capability Statements: The DACT shall provide route (straight or curved) 
distance measuring, coordinates of an operator-designated point on a displayed 
map, and polar coordinates between any two user-designated points. 

Measure: Distance Calculation Accuracy. 

Measure: Route Planning. Pass 

Measure: Direction of Travel Accuracy. Future Test 

Measure: Grid Reference Conversion Accuracy. 

Attribute: PLI 

Capability Statements: A KPP for the DACT consists of the ability to display a 
map with GPS-derived position location information (PLI) [Interoperability KPP] 
represented on the map. 

Measure: Average Time for Updates (5 minutes to receive updated COP). 
Measure: % Completeness. [Completeness of PLI data after receipt (via terrestrial 
and/or satellite communications medium) from adjacent JBC-P FoS terminals, 
JTCW gateway, FBCB2 NOC/FBCB2-BFT L-Band systems.] 

Measure: Change Track View. Not a DACT ORD Requirement 
Measure: Display Accuracy. [Accuracy of PLI displayed.] 

Attribute: Overlays and Symbols 

Capability Statements: The DACT will be used to transmit, receive, store, 
retrieve, create, modify, and display map overlays and commanders’ critical 
information requirements (CCIRs). 

Measure: MAGTF Symbols and Unit Identifiers (Military Standard 2525B). 
Measure: Completeness. [Overlay completeness after transmission]. 

Measure: Unit Symbol Scaling. Not a DACT ORD Requirement 
Measure: Overlay Scaling. 

Measure: % Successful Overlay Creation. 

Measure: Edit. 

Measure: Display. 

Measure: Select-ability. 
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Measure: Transmit. 

Measure: Receive. 

Measure: Store. 

Measure: Retrieve. 

Attribute: Message Handling 

Capability Statements: The DACT will be used to transmit, receive, store, 
retrieve, create, modify, and display map overlays and CCIR 
Measure: Preformatted Message Template Capability. [23 message formats 
according to the DACT ORD. Nine threshold formats at a minimum.] 

Measure: Content Completeness. [Message formats contain mandatory fields.] 
Measure: % of Distribution Completeness. [JBC-P FoS text message distribution 
capability and associated message log/delivery status tools. Message distribution 
to all designated recipients after transmission.] 

Measure: Accuracy. [Accuracy of text messages after distribution to designated 
recipients.] 

Measure: Alerts. [Audio and visual message alert capability] 

Measure: Sorting. [Verify message sort capability.] 

Measure: % Successful Message Creation. 

Measure: Edit. 

Measure: Display. 

Measure: Transmit. 

Measure: Receive. 

Measure: Store. 

Measure: Retrieve. 

Measure: Attachments. 

Attribute: Cryptographic Capability 

Capability Statements: The GPS receiver shall provide the ability to utilize an 
electronically inserted cryptographic key. 

Measure: Verify GPS Cryptographic Capability. 

Attribute: Rapid Purge Function 

Capability Statement: The DACT will have a rapid purge function for critical 
operational information and GPS key (if installed) to guard against hostile 
exploitation. 

Measure: Average purge time (< 10 min). 

Measure: Zeroize GPS Key. 

Measure: Remote Purge. [JBC-P FoS ability to purge hard drive and GPS key 
from a remote location.] 

Attribute: MAGTF Command, Control, Communication, and Intelligence 
Network Interoperability 

Capability Statements: The mounted DACT, when connected to a local network 
segment, must have the capability to connect to existing network printers to allow 
the user to print messages (Threshold) and graphics (Objective). 
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Measure: Interoperability with JTCW. 

Measure: Interoperability with transmission medium (EPLRS). 

Measure: Positive Indication of Connectivity with JTCW Gateway. 

Attribute: Joint and Allied/Coalition C2 System Interoperability 
Capability Statement: The DACT will be in compliance with all appropriate 
options within applicable standards categories of the Department of Defense Joint 
Technical Architecture (JTA) to include information processing standards, 
information transfer standards, information modeling standards, human-computer 
interface standards, and information systems security standards. 

Measure: Net Ready KPP. 

Measure: JITC Certification 

Attribute: Compatibility 

Capability Statements: The DACT shall be capable of sending data via frequency 
hopping radios to reduce the effects of electronic warfare. 

Measure: Compatible with Host Platform. Hardware 

Attribute: Reliability 

Capability Statements: The DACT shall have a threshold mission reliability of 
90% and an objective mission reliability of 95%. This reliability shall include 
both hardware and software. 

Measure: Reliability Growth Plan. 

Measure: Software Metrics. [Reliability Metric—how many faults in the software 
as well as the number of faults expected when the software is used in its intended 
environment.] 

Attribute: Self-Check Capability 

Capability Statements: Upon activating the DACT, a top-level self-check shall be 
performed. If a fault is detected, the DACT shall display an error message 
indicating the fault. 

Measure: Self-Check Capability Present. 

Measure: Self-Check Fault Isolation Accuracy (> 90%). 

Measure: Self-Check False Alarm Rate (< 10%). 

Attribute: Impact on Related Systems 

Capability Statement: Personnel requirements to operate and maintain the DACT 
are based on existing tables of organization and projected task organizations for 
all MAGTFs. 

Measure: Related Systems Training Materials (JTCW and EPFRS) Adequate. 
Fogistics 

Attribute: Audio and Visual Alert 
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Capability Statement: The DACT shall provide an audio and visual alert of 
incoming messages. This alert shall be user selectable: audio, visual, both, or off. 
The audio alert shall have a volume control. 

Measure: Verify audio and visual alert capability. 

Measure: User Selectable On-Off Capability. 

Measure: User Selectable Volume Control. 

Attribute: Text Scrolling and Graphics Panning Function 

Capability Statement: A scrolling or paging capability shall be provided for 
messages that exceed the display capacity. 

Measure: Verify Text Scrolling Capability. 

Measure: Verify Graphics Panning Capability. 

Attribute: Data Input 

Capability Statement: The DACT shall provide the capability for system data 
input and control using a pen stylist or equivalent device, and a keyboard/keypad. 
Measure: Keyboard Adequate. 

Measure: Pen Stylus Adequate. 
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